The present invention relates to methods for a data network according to the preamble of patent claim 1, to systems according to the preamble of claims 2, 4 and 5 and to a storage medium, respectively. In particular, the invention relates to the IPsec standard.
Known from the art is the “IPsec” protocol suite (RFC 2401, http://www.ietf.org/rfc/rfc2401.txt): IPsec is designed to provide interoperable, high quality, cryptographically-based security for the IPv4. and IPv6 protocols. The set of security services offered by IPsec includes access control, connectionless integrity protection of data, data origin authentication, protection against replay attacks, data confidentiality (via encryption), and limited traffic flow confidentiality. These services are provided at the IP layer (network layer), offering protection for IP and for all protocols that may be carried over IP. A common application of IPsec are “virtual private networks” (VPNs).
Further known from the art is the technology of “dynamic routing”, which allows routers to communicate with each other by means of a dynamic routing protocol. Using such a protocol, a router can advertise to a neighbour router which networks are currently reachable through it. A router which receives this reachability information can propagate it to other routers. Thereby, simplified, all routers participating in the dynamic routing protocol know which networks are currently reachable over which paths. This enables failure safety and load balancing within the network as a whole. An example of a dynamic routing protocol is the “Border Gateway Protocol” (BGP, RFC 1771, http://www.ietf.org/rfc/rfc1771.txt).
The two technologies IPsec and dynamic routing are incompatible so far unless extra measures are taken. An explanation and graphical illustration concerning this issue is known from the Internet publication http://www.av8n.com/vpn/mast.htm. The graphical illustration from this Internet publication is reproduced in FIG. 7 in modified form. It shows the processing steps an IPsec-capable data processing apparatus has to carry out for outgoing datagrams. This illustration is not based on the ISO/OSI reference model, but rather on the more practically relevant TCP/IP reference model as described, among other publications, in the book “Computer Networks” by Andrew S. Tanenbaum (ISBN 0-13-394248-1). Its only difference to the ISO/OSI reference model is that the OSI layers 1 and 2 are combined into a single layer, and that the OSI layers 5 and 6 are omitted as they are rarely used in practice. FIG. 7 does employ the numbering scheme of the ISO/OSI reference model however because these numbers are commonly used.
On an IPsec-capable data processing apparatus, an outgoing datagram is first processed by IPsec (layer 3a and 1+2a, reference signs 73 and 74) and then sent out by the normal routing mechanism (layer 3b and 1+2b, reference signs 75 and 76). In the course of this, two routing decisions are made: The first routing decision 73 determines over which IPsec tunnel the datagram is sent. For this, the IPsec data structure “Security Policy Database” (SPD) 14 is used. The second routing decision 75 determines over which physical network interface or, put differently, to which “next hop” 53 the IPsec-processed datagram is sent. For this, the routing table 12 is used. The term “IPsec tunnel” denotes a pair of “Security Associations” (SAs) in “tunnel-mode” according to RFC 2401. Examples of the IPsec data structures outbound SPD 14, inbound SPD 16 and “Security Association Database” (SAD) 21 are depicted in FIG. 2 to 4.
The incompatibility of IPsec and dynamic routing arises because IPsec ignores the reachability information that a data processing apparatus receives by means of a dynamic routing protocol. This reachability information is stored in the routing table 12 by the routing daemon 23 which implements the dynamic routing protocol. IPsec does not consult that data structure.
The consequences of this incompatibility can be observed in the example network depicted in FIG. 6: The three security gateways 61, 62, 63 communicate over the two IPsec tunnels 64, 65 by means of a dynamic routing protocol. If one of the company headquarters' 68 two Internet connections 66, 67 fails, the security gateway 63 in the company branch office 69 learns this via the dynamic routing protocol, and it removes those routes from its routing table that relate to the failed Internet connection. IPsec should now send all data traffic over the tunnel which is running over the functioning Internet connection. This does not take place however, as IPsec ignores the reachability information which was received by means of the dynamic routing protocol. Therefore, the security gateway 63 in the company branch office 69 may continue to send data traffic over the failed tunnel, resulting in packet loss or at worst the complete failure of the VPN, even though a functioning tunnel is still available.
Known from the art is an effort to solve this issue called “IIPtran” (http://www.isi.edu/touch/pubs/draft-touch-ipsec-vpn-04.txt, published on 24 Jun. 2002). IIPtran replaces IPsec tunnel-mode by IPIP tunnels combined with IPsec transport-mode: For outgoing datagrams, tunnel encapsulation occurs as a separate initial step, based on the routing table 12. Only afterwards is the resulting (tunneled) datagram processed by IPsec. Incoming datagrams are processed the other way round. By that means, IPsec is claimed to be compatible with dynamic routing.
An interpretation of this solution, based on the aforementioned way of fitting IPsec into the TCP/IP reference model, is depicted in FIG. 8. Each of the layers 3a, 1+2a, 3b and 1+2b (reference signs 81, 82, 83, 84, 73, 74, 75, 76) is passed through twice. It is the same layer each time, only the point in time when the layer is passed through for the first time and second time differs. In FIG. 8, the two different points in time are distinguished by a single apostrophe or no apostrophe after the layer number.
IIPtran's architecture enforces that before an outgoing datagram is processed by IPsec, it mandatorily passes through layer 3b′ (83) first, where it is encapsulated into an IPIP tunnel based on the dynamically learned reachability information. This is achieved by leaving the datagram unmodified during the first pass through layers 3a′ (81) and 1+2a′ (82). The SPD is configured in such a way that these two layers are effectively skipped during the first pass. It is not until the second pass of the layers 3a (73) and 1+2a (74) that the datagram actually is processed by IPsec.
A disadvantage of IIPtran is that the access control which is integral to IPsec can no longer be used: At the point in time when the access control is applied to an incoming or outgoing datagram by means of the SPD, i.e. at layer 3a (73), the datagram is encapsulated within the IPIP tunnel. The access control can therefore only be applied to the outer IP header (the one of the tunnel), but not to the inner IP header (the one of the datagram).
It is possible to alternatively apply the access control at layer 3b′ (83) by means of a conventional IP packet filter, but then the problem arises that at this point in time, it is no longer known over which Security Association (SA) an incoming datagram was received. Thus, the access control at layer 3b′ (83) can only be applied globally to all IIPtran tunnels, not differently for each IIPtran tunnel. This is a security hole: A data processing apparatus can send a datagram with a forged sender address over an IIPtran tunnel to a second data processing apparatus, if the second data processing apparatus is able to reach over one of its IIPtran tunnels the data processing apparatus to which this sender address actually belongs (“IP spoofing”). In principle, it is possible to save the information over which SA an incoming datagram was received and make it available at layer 3b′ (83), but this is not required by the standards. In addition, some operating systems offer no IP packet filter at all at layer 3b′ (83), or they offer no packet filter with equally powerful matching functions as the SPD.
In an updated version of RFC 2401 (RFC 4301, http://www.ietf.org/rfc/rfc4301.txt), IIPtran is mentioned together with the following warning: “The access control functions that are an important part of IPsec are significantly limited [with IIPtran], as they cannot be applied to the end-to-end headers of the packets that traverse a transport-mode SA used in this fashion. Thus this way of using transport-mode should be evaluated carefully before being employed in a specific context.”
Another disadvantage of IIPtran occurs when multiple IIPtran tunnels need to be configured between two data processing apparatuses. This may e.g. be necessary when the data traffic sent over each of the tunnels is afforded a different quality of service (“Differentiated Services”). IIPtran requires an additional IP address on both endpoints for each of the tunnels, thereby limiting the scalability. In contrast to this, IPsec tunnel-mode does not require additional IP addresses when multiple SAs are configured between two data processing apparatuses.
In a newer version of the IIPtran specification (RFC 3884, http://www.ietf.org/rfc/rfc3884.txt, published on 28 Sep. 2004), in section 4, three alternative attempts to solve the incompatibility between IPsec and dynamic routing are presented together with their individual disadvantages.
A disadvantage of IIPtran and all three alternative solution attempts is that they modify the processing of datagrams (FIG. 7) more or less substantially: IIPtran requires passing through layers 3a, 1+2a, 3b and 1+2b (73, 74, 75, 76) twice. The “Alternative 1” requires changing IPsec so that the SAs of layer 3a and 1+2a (73, 74) are made available as virtual network interfaces at layer 3b (75). The “Alternative 3” requires changing the routing mechanism at layer 3b (75) so that it consults the SAD of layer 3a and 1+2a (73, 74). The “Alternative 2” is impracticable according to section 4.2.1 of the IIPtran specification.
These modifications make the processing of datagrams more complicated and non-transparent. As the probability that a system contains a security vulnerability grows proportionally to the system's complexity, these modifications increase the risk that implementations are affected by security defects. At the same time, it becomes more difficult for security professionals to analyze the protocol and its implementations for security defects.
Another disadvantage of IIPtran is finally that passing through layers 3a, 1+2a, 3b and 1+2b (73, 74, 75, 76) twice reduces the performance.
It is one object of the present invention to establish compatibility between IPsec and dynamic routing without adversely affecting the access control which is integral to IPsec.
This object is achieved by the teachings of the independent claims.
Preferred embodiments of the invention are the subject matter of the dependent claims.
It is one advantage of the present invention that it does not require additional IP addresses when multiple IPsec tunnels need to be configured between two data processing apparatuses. It is a further advantage of the invention that it does not require modifications to the processing of datagrams.